Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000120_owner-urn-ietf _Tue Oct 29 20:02:39 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA22121 for urn-ietf-out; Tue, 29 Oct 1996 20:02:39 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA22116 for <[e-mail]>; Tue, 29 Oct 1996 20:02:37 -0500
Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA07434  (mail destined for [e-mail]); Tue, 29 Oct 96 20:02:31 -0500
Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id RAA26180; Tue, 29 Oct 1996 17:00:56 -0800 (PST)
Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id RAA21309; Tue, 29 Oct 1996 17:01:25 -0800 (PST)
Date: Tue, 29 Oct 1996 17:01:25 -0800 (PST)
From: Terry Allen <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: [URN] some comments
Sender: [e-mail]
Precedence: bulk
Reply-To: Terry Allen <[e-mail]>
Errors-To: [e-mail]

Karen writes:
| Not being a big fan of character set wars, I've sat by the sidelines

I hope we haven't been warring.  I just caught up on FTPEXT (where,
incidentally, Unicode is also an issue), and *that's* war.

| 1) There were a couple of almost parenthetical comments about the
| NAPTR proposal that made me worry.  It is important that we all agree
| that a URN syntax is independent of the NAPTR or any other URN
| resolution proposal.

Absolutely.  And, skipping the discussion of "urn:", I believe
this is relevant to your last point:

| Now, my one other comment relates to an earlier topic - security.  I
| am in complete agreement with Ron (and whoever else) who said that
| security (and let's make sure we include integrity of the information
| in "security") that no one (user or publisher) should be required to
| support security and integrity.  But...if the infrastructure
| supporting URN resolution (which IS the topic of discussion for this
| WG) is to be able to provide security and integrity for anyone, there
| may be some requirements it will place on its clients (users and
| publishers).  I would like to be confident that we are all in
| agreement about the following: in the case where there are security
| measures that must be in place within the infrastructure in order to
| provide security (at some agreed upon level) to those who want it,
| even if that imposes some security requirements on those who don't
| want it, that the choice of having the security mechanisms in place
| will take precedence over not have the mechanisms.  Of course, within
| that constraint, wherever security isolation can be provided, security
| mechanisms should NOT be required.

You phrase this as a general matter, and we clearly cannot pretend
to govern all resolutions methods.  As a trivial example, one method
of URN resolution is the publication of physical books containing
URNs and other information.  Some URNs may be resolvable only by
such non-Internet means.  Suppose the government were to insist that
copies of such books that are sold to the government must be printed on
tamper-resistant paper (someone wanting security).  Is that something
this group should concern itself with?

I don't think so, I don't think that one can speak of *the*
"infrastructure supporting URN resolution," and so I don't agree
with your very general statement.  Can you sharpen it up some?


Regards,
    Terry Allen    Fujitsu Software Corp.    [e-mail]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html